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Beschreibung 

Verkniipfung und Darstellung von Signalen einer Vorrichtung 
zur Hardware-Simulation und Elementen eines Listings eines 
5 Programms 

Die Erfindung betrifft ein System sowie ein Verfahren zur 
Darstellung von Signalen einer Vorrichtung zur Hardware- 
Simulation sowie ein Fehlersuchwerkzeug. 

10 

Aus US 5 7 68 567 ist ein Hardware-Sof tware-Cosimulator zur 
Simulation eines Hardware-Software-Systems bekannt, welcher 
einen logischen Simulator, Busschnittstellenmodelle, Spei- 
chermodelle, Befehlssatzsimulatoren und einen sogenannten Co- 

15 simulations-Optimierungs-Manager aufweist. Die gleichzeitige 
Simulation von Hardware und Software wird auch Cosimulation 
genannt. Dabei wird die Cosimulation mit einem einzigen koha- 
renten Blick auf den Speicher des Hardware-Software-Systems 
durchgeftthrt, welcher durch den Cosimulations-Optimierungs- 

20 Manager sowohl fur Hardware- als auch fur Sof tware-Simulatio- 
nen transparent aufrechterhalten wird, 

Der Erfindung liegt die Aufgabe zugrunde, die gemeinsame Dar- 
stellung von Signalen einer Vorrichtung zur Hardware- 
25 Simulation und Elementen eines Listings eines Programms zu 
ermoglichen. 

Diese Aufgabe wird durch ein System zur Verkniipfung und Dar- 
stellung von Signalen einer Vorrichtung zur Hardware- 
30 Simulation und Elementen eines Listings eines Programms ge- 
lost, 

• wobei die Vorrichtung zur Hardware-Simulation das Verhal- 
ten einer Schaltung mit einem Prozessor, einem Programm- 
speicher, welcher den Programmcode des Programms enthalt, 
35 und applikationsspezif ischen Hardwarekomponenten simuliert 
und Signale als Ergebnis der Simulation erzeugt, 
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• wobei die Elemente des Listings des Programms mit den bei 
der simulierten Ausftihrung des im Programmspeicher enthal- 
tenen, mit diesen Elementen korrespondierenden Programmco- 
des erzeugten Signalen verkntipft werden, 

5 • wobei die Elemente des Listings des Programms in einem 

ersten Teilbereich eines grafischen Anzeigemittels und die 
Signale in einem zweiten Teilbereich des Anzeigemittels 
darstellbar sind. 

Diese Aufgabe wird durch ein Verfahren zur Verkntipfung und 
Darstellung von Signalen einer Vorrichtung zur Hardware- 
Simulation und Elementen eines Listings eines Programms ge- 
lost, 

• wobei die Vorrichtung zur Hardware-Simulation das Verhal- 
ten einer Schaltung mit einem Prozessor, einem Programm- 
speicher, welcher den Programmcode des Programms enthalt, 
und applikationsspezif ischen Hardwarekomponenten simuliert 
und Signale als Ergebnis der Simulation erzeugt, 

• wobei die Elemente des Listings des Programms mit den bei 
der simulierten Ausfuhrung des im Programmspeicher enthal- 
tenen, mit diesen Elementen korrespondierenden Programmco- 
des erzeugten Signalen verkniipft werden, 

• wobei die Elemente des Listings des Programms in einem 
ersten Teilbereich eines grafischen Anzeigemittels und die 
Signale in einem zweiten Teilbereich des Anzeigemittels 
dargestellt werden. 

Diese Aufgabe wird durch ein Fehlersuchwerkzeug zur Verkniip- 
fung und Darstellung von Signalen einer Vorrichtung zur Hard- 
30 ware-Simulation und Elementen eines Listings eines Programms 
gelost, 

• wobei die Vorrichtung zur Hardware-Simulation das Verhal- 
ten einer Schaltung mit einem Prozessor, einem .Programm- 
speicher, welcher den Programmcode des Programms enthalt, 

35 und applikationsspezif ischen Hardwarekomponenten simuliert 
und Signale als Ergebnis der Simulation erzeugt, 
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• wobei das Fehlersuchwerkzeug Mittel zur Verknupfung der E- 
lemente des Listings des Programms mit den bei der simu- 
lierten AusfUhrung des im Programmspeicher enthaltenen, 
mit diesen Elementen korrespondierenden Programmcodes er- 
5 zeugten Signalen aufweist, 

wobei die Elemente des Listings des Programms in einem ersten 
Teilbereich eines grafischen Anzeigemittels und die Signale 
in einem zweiten Teilbereich des Anzeigemittels darstellbar 
sind. 

10 

Der Erfindung liegt die Erkenntnis zugrunde, dass das Design 
von Hardware-Software-Systemen durch eine verkntipfte Darstel- 
lung der Signale eines Hardware-Simulators und der Elemente 
des Listings eines Programms wesentlich vereinfacht wird. Das 

15 erf indungsgemafte System und Verfahren ermoglicht eine einfa- 
che und fehlersichere Verfolgung der Ausfiihrung eines Pro- 
gramms. Die Darstellung des Listings des Programms stellt ei- 
nen direkten Bezug zum eigentlichen Programm her, insbesonde- 
re konnen auch aufgrund der Verwendung des Listfiles die im 

20 Original-Quelltext eingeftigten Kommentare angezeigt werden. 
Zur Verknupfung und Darstellung der Signale der Vorrichtung 
zur Hardware-Simulation und der Elemente des Listings des 
Programms ist das Vorliegen eines abstrahierten Software- 
Modells des Prozessors nicht erf orderlich. Es ist somit ge- 

25 wahrleistet, dass tatsachlich der in der Schaltung verwendete 
Prozessor simuliert wird. Somit werden durch eine Beschrei- 
bung des Prozessors mittels eines Modells verursachte Fehler 
bei der Simulation ausgeschlossen. Die Visualisierung des 
Programmablauf s erfolgt in ahnlicher Form wie bei ublichen 

30 Entwicklungswerkzeugen zum Debuggen von reiner Software, Die 
Einarbeitungszeit ftir Anwender des Systems bzw. des Verfah- 
rens, welche Erfahrung bei der Entwicklung von Software oder 
Firmware haben, ist daher relativ gering, 

35 GemaJi einer vorteilhaf ten Ausgestaltung der Erfindung ist ei- 
ne Markierung eines Elements des Listings des Programms im 
ersten Teilbereich des grafischen Anzeigemittels und eine 
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Markierung der mit diesem Element verknupften Signale im 
zweiten Teilbereich des Anzeigemittels vorgesehen. Die grafi- 
sche Darstellung orientiert sich soiait an tiblichen Software- 
Debug-Werkzeugen. Der Programmverlauf kann durch eine Markie- 
rung eines Elements des Listings des Programms verfolgt wer- 
den. Im zweiten Teilbereich des Anzeigemittels bewegt sich 
eine Markierung synchronisiert zur Markierung im ersten Teil- 
bereich des Anzeigemittels, so dass auch Querbeziehungen zur 
iibrigen Hardware erfasst werden konnen. 

Vorteilhafterweise ist ein dritter Teilbereich des grafischen 
Anzeigemittels zur Darstellung mindestens eines Teils der 
Signale, insbesondere weiterer Werte, vorgesehen. Weitere 
Werte konnen beispielsweise Registerwerte sein. 

Die Verwendung ublicher Vorrichtungen zur Hardware-Simulation 
wird erleichtert, wenn gemaii einer vorteilhaf ten Ausgestal- 
tung der Erfindung die Schaltung mit dem Prozessor, dem Pro- 
grammspeicher und den applikationsspezif ischen Hardwarekompo- 
nenten in einer Hardware-Beschreibungssprache beschrieben 
sind. 

Das System lasst sich mit geringem Aufwand an verschiedene 
Prozessoren anpassen, wenn gemaft einer vorteilhaf ten Ausges- 
taltung der Erfindung Mittel zum Anpassen des Systems an ver- 
schiedene Prozessortypen vorgesehen sind. 

Nachfolgend wird die Erfindung anhand der in den Figuren dar- 
gestellten Ausftihrungsbeispiele naher beschrieben und erlau- 
tert. 

Es zeigen: 

FIG 1 eine schematische Darstellung eines Systems zur 

Verkniipfung und Darstellung von Signalen einer Vor- 
richtung zur Hardware-Simulation und Elementen ei- 
nes Listings eines Programms, - 
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FIG 2 einen Ausschnitt einer Darstellung von Signalen ei- 
ner Vorrichtung zur Hardware-Simulation und 

5 FIG 3 eine Darstellung von Signalen einer Vorrichtung zur 

Hardware-Simulation und Elementen eines Listings 
eines Programms. 

FIG 1 zeigt ein System zur Verknupfung und Darstellung von 

10 Signalen 4, 5 einer Vorrichtung zur Hardware-Simulation 1 und 
Elementen 15 eines Listings 2 eines Programms 3 in schemati- 
scher Darstellung. Die Vorrichtung zur Hardware-Simulation 1 
simuliert das Verhalten einer Schaltung 6 mit einem Prozessor 
7, einem Programmspeicher 8 und applikationsspezif ischen 

15 Hardwarekomponenten 10. Der Prozessor 7 kann z. B. ein Mikro- 
prozessor oder Mikrocontroller sein. Der Programmspeicher 8 
enthalt den Programmcode 9 des Programms 3 . Die Schaltung 6 
wird mit Hilfe einer Hardware-Beschreibungssprache, abgekiirzt 
HDL (HDL = Hardware Description Language) , im Ausfuhrungsbei- 

20 spiel mittels VHDL (VHDL = Very High Speed Integrated Circuit 
Hardware Description Language) beschrieben. Mit dem Bezugs- 
zeichen 17 wird der Quellcode in VHDL bezeichnet. Die Vor- 
richtung zur Hardware-Simulation 1 wird entsprechend auch als 
HDL-Simulator bezeichnet. Ein Beispiel fiir einen HDL- 

25 Simulator ist das Produkt "ModelSim" der Firma Model Techno- 
logy, Portland, Oregon, USA. Die Schaltung 6 ist z. B. ein 
sogenannter ASIC (ASIC = Application Specific Integrated Cir- 
cuit = Anwendungsspezif ische integrierte Schaltung) . Der HDL- 
Quellcode 17 wird mit einem geeigneten Compiler in ein HDL- 

30 Simulator-Format 18 umgewandelt, welches von der Vorrichtung 
zur Hardware-Simulation 1 verarbeitet werden kann. Die Vor- 
richtung zur Hardware-Simulation 1 erzeugt Signale 4, 5 als 
Ergebnis der Simulation. Das Programm 3, bzw. der Programmco- 
de 9 des Programms 3 wird mittels eines Compilers in ein Da- 

35 tenfile 16 (tiblicherweise mit Daten in hexadezimaler Form) 
und ein Listing 2, auch Listfile genannt, umgewandelt. Das 
Listing 2 enthalt sowohl die Programmbef ehle als auch die zu- 
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gehorigen Kommentare. Das Listing 2 ist zeilenweise aufge- 
baut, wobei jede Zeile jeweils einen Programmbef ehl bzw. eine 
Anweisung enthalt, gegebenenf alls mit dem zugehorigen Kommen- 
tar. Eine Zeile, ein Programmbef ehl, eine Anweisung bzw. ein 
5 Kommentar sind Elemente 15 des Listings 2. Ein Debugger 19 
verkniipft die Elemente 15 des Listings 2 des Programms 3 mit 
den bei der simulierten Ausftihrung des im Programmspeicher 8 
enthaltenen, mit diesen Elementen 15 korrespondierenden Pro- 
grammcodes 9 erzeugten Signalen 4, 5. Die Elemente 15 des 
10 Listings 2 des Programms 3 werden in einem ersten Teilbereich 
11 des grafischen Anzeigemittels 14 und die Signale 4, 5 in 
einem zweiten Teilbereich 12 bzw. in einem dritten Teilbe- 
reich 13 des Anzeigemittels 14 dargestellt. 

15 FIG 2 zeigt einen Ausschnitt 30 einer Darstellung von Signa- 
len 4, 5 einer Vorrichtung zur Hardware-Simulation 1. Die 
Signale 4, 5 werden als sogenannte Waveforms 35, 3 6 und 37 
dargestellt . 

20 FIG 3 zeigt eine Darstellung 23 von Signalen 4, 5 einer Vor- 
richtung zur Hardware-Simulation 1 und Elementen 15 eines 
Listings 2 eines Programms 3. Die Elemente 15 des Listings 2 
werden in einem ersten Teilbereich 11, die Signale 4, 5 in 
einem zweiten 12 bzw. einem dritten 13 Teilbereich eines An- 

25 zeigemittels 14 dargestellt. Die Elemente 15 konnen mit einer 
Markierung 20, z. B. einer farblichen Kennzeichnung, versehen 
werden. Die Signale 4 konnen mit einer Markierung 21, z. B. 
einem Cursor, gekennzeichnet werden. Ein Anzeigemittel 14 
kann eine Bildschirmoberf lache sein, die Teilbereiche 11 bis 

30 13 konnen als Anzeigef enster realisiert sein. Der Ablauf des 
Programms 3 im Prozessor 7 (siehe FIG 1) wird mit Hilfe des 
grafischen Frontends, des Debuggers 19, welcher auf die Sig- 
nale 4, 5 der Vorrichtung zur Hardware-Simulation 1 aufsetzt, 
visualisiert . Die Visualisierung des Programmablauf es erfolgt 

35 durch Zugriff auf Signale des Prozessors 7, deren Werte durch 
die Vorrichtung zur Hardware-Simulation 1 berechnet wurden. 
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GemaJi dem Ausftlhrungsbeispiel ist der Debugger 19 in der 
Skriptsprache TCL/TK realisiert (TCL/TK = Tool Command Langu- 
age/Toolkit) und benutzt die TCL/TK-Schnittstelle zu HDL- 
Objekten, die ein HDL- Simulator zur Verfugung stellt. Solche 
5 HDL-Objekte konnen z. B. als Waveforms dargestellt werden. Urn 
den Debugger 19 moglichst flexibel zu gestalten, d. h. in 
diesem Zusammenhang, dass er relativ einfach an verschiedene 
Prozessoren angepasst werden kann, wird der Debugger 19 in 
zwei Abschnitte aufgeteilt. Ein erster allgemeiner Teil 
10 stellt Prozeduren zur Visualisierung bereit. Ein zweiter pro- 
zessorspezifischer Teil ist dem jeweiligen Prozessor anpass- 
bar und setzt sich z. B. aus folgenden Prozeduren zusammen: 

• Prozeduren fur Single-Step rechts/links 

• Prozeduren zum Bestimmen der Registerwerte 

15 • Prozeduren far die Kopplung von Signalen und Elementen des 
Listings 

• Prozeduren zur Konf iguration 

In den Prozeduren fur Single-Step rechts/links (Bezugszeichen 
20 22 in FIG 3) wird der Cursor in einem Waveform- Fenster auf 
den nachsten gtiltigen Befehl gesetzt. FUr das Beispiel eines 
KRISC8-Prozessors (KRISC8 = Kommunikations-RISC 8 Bit, Spezi- 
al-Core fur die Kommunikation in Feldbussystemen der Firma 
Siemens AG, Miinchen, Deutschland) ist dies in FIG 2 veran- 
25 schaulicht, 

Der im Folgenden wiedergegebene Ausschnitt aus einem Listing 
zeigt eine Prozedur fur Single-Step-Right. 
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8 Prozedur fQr Single-Step-Right 

8 ACHTUNG: pc muss im Wave-Fenster selektiert sein {Das right-Kommando wirkt auf das 
ft selektierte Signal )!!!!! 

proc right_krisc8 . Proc {} { 

global minideb 

global DEBUG 

set time_now [1 index [getactivecursortime] 0] 

set address (examine -time $time_now $minideb(TIMEJJNIT) -hex $minideb (pc-path ) ] 
set address_tmp [examine -time [expr $time_now + $minideb (CLK_PERIOD) ] $ minideb (TIME_UNIT) -hex 
$minideb(pc-path) ] 
set i 1 

if {$ DEBUG — "on"} {echo "anfang von right. Proc"} 
if {$address_tmp n No_Data"} { 

.mainFrame.labeljnessage configure -bg DimGray -fg red -text "End of Simulation reached," 

set minideb (auto_step_right) 0 

.mainFrame. f rame_toolbar . autostep_right configure -background grey - act ivebackg round khaki2 

.mainFrame. f rame_toolbar.label__info configure -text 

return 

} 

# Anfang vom naechsten Befehl suchen 
while {$address = $address_tmp} { 

if { $ DEBUG "on"} {echo "right. Proc: while-Schleif e 1"} 

incr i 

set address_tmp [examine -time [expr $time_now + $i * $minideb (CLK_PERIOD) ] $minideb [TIME_UNIT ) 
-hex $minideb(pc-path) } 
} 

set time_now [expr $time_now + $i * $minideb{CLK_PERIOD) ) 

if {$ DEBUG — "on"} {echo "right. Proc: time_now — > $time_now"} 

set schleife 1 

8 Suche den naechseten gueltigen Befehl 
while {$schleife — 1} { 

if {$ DEBUG — "on"} {echo "right. Proc: while-Schleife 2"} 

0 Ende des Befehls suchen 

set address [examine -time $time_now $ minideb (TIME^UNIT) -hex $minideb {pc-path) ] 
set address_tmp (examine -time [expr $time_now + $minideb (CLK_PERIOD) ] $minideb(TIME_UNIT) -hex 
$minideb (pc-path) 1 

if ($address_tmp « "No_Data"} { 
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.mainFrame.label_raessage configure -bg DimGray -fg red -text "End of Simulation reached." 
set minideb(auto_step_right) 0 

.mainFrame.frame_toolbar.autostep_right configure -background grey -activebackground khaki2 

.mainFrame.frame_toolbar.label_info configure -text "«' 

return 

) 

set i 1 

while {$ address ~ $address_tmp) { 

if {$ DEBUG = "on") {echo "right. Proc: while-Schleife 3"} 
incr i 

set address_tmp [examine -time (expr $time_now + $i * $minideb (CLK_PERIOD) ] $mini- 
deb ( TIME_UNIT ) -hex $minideb(pc-path) ] 
} 

set time__now_tmp (expr $time_now + $i * $minideb (CLK_PERIOD) ] 
8 Befehl ist 16 Bit breit? 

set instruction [examine -time $time_now $mi nideb ( TIME__UNIT ) -hex $minideb ( instruction) 1 

set digit [split $instruction nn ] 

set kl " [lindex $digit 0) [lindex $digit 1]" 

if {$ DEBUG = "on") {echo "right. Proc: splitted instruction — > <$kl>"} 
if {$kl == "IE" } { 

8 Befehl ist 16 Bit breit f 1 Befehl weitergehen 

if { $ DEBUG = "on"} {echo "right. Proc: 16 Bit Befehl") 

set time_now $time_now_tmp 
) else { 

set read_time [expr $time_now_tmp - 0.5 * $minideb(CLK_PERIOD) ] 

if { $ DEBUG «= "on") {echo "right . Proc: time__now — > $time_now; time_now_tmp — > 

$time_now_tmp; read_time — > $read_time") 

if {$ DEBUG == "on") {echo "en_pipe — > (examine -time $read_time $mi nideb (TIME_UNIT) -bin 

$minideb ( en_pipe ) ) ; \ 

res_pipe — > (expr {[examine -time $read_time $minideb ( TIME__UNIT ) 

-bin $minideb(res_pipe) } ) ") 

if {[examine -time $read_time $minideb(TIME_UNIT) -bin $minideb(en_pipe) ) && [[examine -time 
$read_time $minideb[TIMEJJNIT) -bin $minideb( res__pipe) ) ) { 
ff naechsten gueltigen Befehl gefunden 
set schleife 0 
) else { 

if {$ DEBUG >== "on") {echo "right. Proc: Der Befehl ist ungueltig!") 
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8 Befehl wird nicht ausgefuehrt, da 
# - pipe enable nicht gesetzt ist 
8 - pipe reset gesetzt ist 
8 1 Befehl weiter gehen 
set time_now $time_now_tmp 

) 

} 

} 

set address_int {examine -time $time__now $minideb (TIMEJJNIT) -hex $minideb (pc-path) ] 
if {[catch { .$minideb{wave_name) .tree right -value 1 h$address_int 1} result] !»0} { 

8 Wenn PC nicht markiert ist, deaktiviere Auto-Step und zeige eine Fehlermeldung an 

set minideb(auto_step_right) 0 

.mainFrame.f rame_toolbar.autostep_right configure -background grey -activebackground khaki2 
.mainFrame.frame_toolbar.label_info configure -text 
notice_show "$result \nPlease select pc in the wave-Window! " 

) 

trace. Proc 
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Dabei wird vereinfacht wie folgt vorgegangen (siehe FIG 2) : 

• Zum momentanen Simulations zeitpunkt wird der Wert des Pro- 
grammcounters 36 (pc, Programmcounter = Programmzcihler ) 
ermittelt. Der momentan ausgefiihrte Befehl ist in FIG 2 

5 mit dem Bezugszeichen 31 gekennzeichnet) 

• Der Beginn des nachsten Befehles wird gesucht. Der Cursor 
wird solange um Vielfache der Taktperiode weitergeschoben, 
bis eine Anderung des Programmzahlers auftritt. 

• Es wird uberpriift, ob der nun erreichte Befehl ausgeftthrt 
10 wird. 

• Handelt es sich urn einen Befehl, welcher nicht ausge- 
ftihrt wird, so wird der ubernachste Befehl getestet 
(Wiederholung solange, bis ein ausgefUhrter Befehl er- 
reicht ist Oder das Simulationsende erreicht ist) ♦ Im 

15 Beispielsfall gemafi FIG 2 sind die nicht ausgefuhrten, 

d. h. ungliltigen Befehle mit dem Bezugszeichen 32 ge- 
kennzeichnet. 

• Wird der erreichte Befehl ausgefiihrt, dann wird der Cur- 
sor im Waveform- Fenster (entspricht dem zweiten Teilbe- 

20 reich 12 des Anzeigemittels 14 gemaft FIG 3) zu diesem 

Zeitpunkt platziert. Im Beispielsfall gemafi FIG 2 ist 
der nachste ausgefiihrte, d. h. gultige Befehl mit dem 
Bezugszeichen 33 gekennzeichnet. 

25 Die Ermittlung des gtiltigen Befehls erfolgt prozessorspezi- 
fisch. Es genugt bei modernen Prozessorarchitekturen tibli- 
cherweise nicht, den Programcounter 36 zu verfolgen, sondern 
es sind zusatzliche Signale 4, 5 auszuwerten, die angeben, ob 
der momentane Befehl giiltig ist (z. B. das der Waveform 34 

30 zugrundeliegende Signal) . Wenn ein gultiger Befehl ermittelt 
wurde, so erfolgt die Markierung 20 des momentan ausgefuhrten 
Befehls im angezeigten Listing im ersten Teilbereich 11 des 
Anzeigemittels 14 und es werden die Registerwerte im dritten 
Teilbereich 13 des Anzeigemittels 14 angezeigt (siehe folgen- 

35 den Ausschnitt eines Listings) . 
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proc trace. Proc {} { 
global progadr_alt 
global minideb 
global DEBUG 
5 if {$minideb (configure_done) =1} { 

if {$minideb (cursor_move__enable) =1) { 
DisableCursorMove . Proc 

} 

# Programmzaehler auslesen 

10 set timenow [1 index [ get activecursor time] 0] 

fl aktuelle Programmadresse lesen 

if {$ DEBUG — "on"} {echo "trace . Proc: timenow eingelesen"} 

set progadr (string tolower [examine -time $timenow $minideb{TIMEJJNIT) -hex $minideb(pc- 

path))} 

15 if {$ DEBUG == "on"} {echo "trace. Proc: progadr gelesen <$progadr>" } 

# Programmadresse ist undefiniert (Anfang von der Simulation) ? 
if Utregexp { [0-9a-fA-F] + } $progadr) } { 

set progadr 0 

} 

20 # gelesenen Programmcounter mit 2 multiplizieren, urn die Programmadresse zu erhalten (bei NIOS) 

# vorangestellte Nullen werden abgeschnitten 

# da mit hex-Zahlen nicht gerechnet werden kann, wird auf eine Dezimalzahl umgerechnet, 

# das Ergebnis mit 2 multipliziert {bei NIOS, 1 bei KRISC) und anschliefiend wieder in eine 

# hex-Zahl konvertiert. 

25 set progadr_int [hex2int $progadrl 

set progadr_int [expr $minideb ( adressmultiplikator ) *$progadr_int] 
set progadr [int2hex $progadr_int } 

SearchCodeLine. Proc $progadr 
30 GetRegisterValues_$minideb(mode) .Proc 

set progradr_alt $progadr 
) else { 
bell 

.mainFrame. label_message configure -bg DimGray -fg red -text "Before tracing you have to configu- 
35 re the program." 
} 

) 
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Urn den simulierten Ablauf eines Programms 3 auf einem Prozes- 
sor 7 zu verfolgen, gab es bisher keine zuf riedenstellenden 
Moglichkeiten. Die manuelle Verfolgung des Programmablauf es 
anhand der von einem Simulator ausgegebenen Waveform und ei- 
5 nem Ausdruck eines Listfiles hat den Nachteil, dass bei den 
ublicherweise verwendeten Prozessoren (Pipelines, Caches, 
u. A.) eine Programmverf olgung sehr aufwendig und fehler- 
trachtig wird. Bei einer Verfolgung des Programmablauf es an- 
hand eines Disassemblerausdruckes muss ein Benutzer keine di- 

10 rekte Auswertung der Waveform vornehmen. Es wird nur eine 

Liste der vom Prozessor bearbeiteten Befehle ausgegeben. So- 
mit fehlt aber der direkte Bezug zum eigentlichen Programm 
und damit werden auch die im Quelltext eingefugten Kommentare 
nicht angezeigt. Beim Verwenden eines Debuggers, der auf ein 

15 abstrahiertes C-Modell aufsetzt, ergeben sich im Wesentlichen 
zwei Nachteile. Zum einen benotigt man ein C-Modell fur den 
eingesetzten Prozessor, welches normalerweise nicht vorliegt 
und somit aufwendig erstellt werden muss. Zum anderen stellt 
das C-Modell des Prozessors eine erneute Beschreibung des 

20 Prozessors dar und es ist nicht ausgeschlossen, dass der tat- 
sachliche Prozessor ein vom C-Modell abweichendes Verhalten 
aufweist. Da bei dem hier vorgeschlagenen Verfahren kein C- 
Modell fur den Prozessor 7 benotigt wird, ist zum einen ge- 
wahrleistet, dass der gleiche Prozessor 7 simuliert wird, der 

25 auch in der Schaltung 6 implementiert ist. Zum anderen halt 
sich der Auf wand zum Anpassen des Debuggers 19 an verschiede- 
ne Prozessoren 7 bzw. Prozessortypen in Grenzen. 

Zusammengefasst betrifft die Erfindung somit ein System und 
30 ein Verfahren zur Verkniipfung und Darstellung von Signalen 4, 
5 einer Vorrichtung zur Hardware-Simulation 1 und Elementen 
15 eines Listings 2 eines Programms 3 sowie ein Fehlersuch- 
werkzeug. Urn eine gemeinsame Darstellung der Signale der Vor- 
richtung zur Hardware-Simulation und der Elemente des Lis- 
35 tings des Programms zu ermoglichen, wird vorgeschlagen, dass 
die Vorrichtung zur Hardware-Simulation 1 das Verhalten einer 
Schaltung 6 mit einem Prozessor 7, einem Programmspeicher 8, 
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welcher den Programmcode 9 des Programms 3 enthalt, und ap- 
plikationsspezif ischen Hardwarekomponenten 10 simuliert und 
Signale 4, 5 als Ergebnis der Simulation erzeugt, dass die E- 
lemente 15 des Listings 2 des Programms 3 mit den bei der si- 
5 mulierten Ausftahrung des im Programmspeicher 8 enthaltenen, 
mit diesen Elementen 15 korrespondierenden Programmcodes 9 1 
erzeugten Signalen 4, 5 verknttpft werden und dass die Elemen- 
te 15 des Listings 2 des Programms 3 in einem ersten Teilbe- 
reich 11 eines grafischen Anzeigemittels 14 und die Signale 
10 4, 5 in einem zweiten Teilbereich 12 des Anzeigemittels 14 
darstellbar sind. 

Im Folgenden werden der technische Hintergrund der Erfindung 
und verwendete Begriffe naher erlautert. 

15 

Die beschriebenen Schaltungen werden z. B. in sogenannten 
eingebetteten Systemen (gebrauchlicher ist der. entsprechende 
englische Begriff "embedded systems") eingesetzt. Beispiele 
fttr Programmiersprachen fttr den Einsatz in eingebetteten Sys- 

20 temen sind C, Assembler, C++ und Java. Diesen Sprachen ge- 

meinsam ist der Einsatz eines Compilers, der eine schrittwei- 
se Vorgehensweise bei der Codeentwicklung vorschreibt, die 
sogenannten edit-compile-load-debug Zyklen. Debugger genannte 
Fehlersuchwerkzeuge werden allgemein verwendet, uin Fehler in 

25 der Sof tware-Programmierung aufzuspuren. Da die meisten Soft- 
ware-Entwicklungssysteme hierftir eine integrierte Entwick- 
lungsumgebung zur Verfiigung stellen, konnen Debugger relativ 
einfach den Programmcode verandern und mit Einzelschritten o- 
der gesetzten Kontrollpunkten auf ihrem Zielsystem uberprti- 

30 fen. Man kann damit ein Programm kontrolliert ausfuhren, also 
das Programm Zeile fur Zeile ausfuhren und die Werte von Va- 
riablen abfragen und andern. Software Debugger bieten folgen- 
de Basisfunktionen an: 



• Einzelschritt-Ausflihrung von Assembler- und Hochspra- 
chencode 
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• Setzen von Haltepunkten (Breakpoints) an definierten 
Stellen in Hochsprache oder Maschinencode, an denen das 
Programm voriibergehend angehalten wird 

• Anzeigen von Variablenwerten, logischen Ausdrttcken, 
5 Speicheradressen und CPU-Registern 

TCL ist eine plattformiibergreif ende Script-Programmier- 
sprache. Durch die Kombination aus Textverarbeitungs-, Datei- 
bearbeitungs- und Systemsteuerungsfunktionen ist TCL ftir die- 
10 sen Zweck optimiert. EDA-Tools (EDA = Electronic Design Auto- 
mation) verwenden TCL haufig zusammen rait dem Graf ik-Toolkit 
TK, urn eine flexible und plattformunabhangige grafische Be- 
nutzeroberflache zu bieten. Hierzu gehort beispielsweise Mo- 
dels im. 

15 

Im Bereich der eingebetteten Systeme hat der parallele Ent- 
wurf von Hardware und Software den klassischen, rein sequen- 
tiellen Entwurf sablauf weitgehend abgelost. Eingebettete Sys- 
teme spielen eine dominierende Rolle in der Automatisierungs- 

20 technik. Basis ihres Erfolgs ist die exponentiell steigende 

Komplexitat integrierter Schaltungen und die damit wachsenden 
Moglichkeiten fur neue Systemfunktionen, die zunehmend in 
Software realisiert werden. Die daraus resultierende System- 
komplexitat verlangt bei gleichzeitig absinkenden Entwick- 

25 lungszeiten eine drastische Erhohung der Entwurf sproduktivi- 
tat. Diese Erhohung ist nur durch Entwurf sautomation und sys- 
tematische Wiederverwendung von Systemfunktionen erreichbar. 
Ein wesentlicher Schritt ist die Integration von Hardware- 
und Softwareentwurf , der Hardware/Sof tware-Coentwurf . 

30 

Hardware- und Softwareentwurf beginnen oft vor der Vollendung 
der Systemarchitektur oder gar vor der endgiiltigen Festlegung 
der Spezifikation. Systemarchitekten, Anwender und Kunden o- 
der Marketingexperten entwickeln gemeinsam Anforderungsdef i- 
35 nition und Spezifikation. Der Systemarchitekt entwickelt dar- 
aus ein System kooperierender Systemfunktionen als Grundlage 
eines anschlielienden, parallelen Entwurfs von Hardware und 
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Software. An dieser Stelle wird auch die Grobarchitektur der 
Zielhardware festgelegt. Der Hardware-/Sof tware-Schnitt- 
stellenentwurf erfordert eine Beteiligung von Hardware- und 
Softwareentwicklern. Die Integration der Hardware und Soft- 
5 warekomponenten und der Test des integrierten Systems folgt 
als letzter Schritt. In alien Phasen fuhren Abweichungen von 
erwarteten Entwurf sergebnissen oder Anderungen der Spezifika- 
tion zu einer Wiederholung von Entwurf sschritten. Ein zentra- 
les Problem im Entwurf sprozess ist die ttberwachung und Integ- 
10 ration des parallelen Hardware- und Sof tware-Entwurf s . Eine 
frtihe Fehlererkennung erfordert die Kontrolle von Konsistenz 
und Korrektheit, die um so aufwendiger wird, je detaillierter 
der Entwurf ausgearbeitet ist. 

15 Bei der Hardware-Software Cosimulation wird die Ausfuhrung 

der Software auf der (Prozessor-) Hardware zusammen mit appli- 
kationsspezif ischen Hardwarekomponenten simuliert. Da eine 
Simulation mit hohem Detaillierungsgrad, wie er im Hardware- 
entwurf tiblich ist, zu langsam fur eine praktisch nutzbare 

20 Softwaresimulation ist, werden ublicherweise abstrakte Pro- 
zessormodelle benotigt. Zu diesem Zweck werden die Prozesso- 
ren abstrakter (*auf einer hoheren Abstraktionsebene" ) model- 
liert als die anderen Hardwarekomponenten. Dabei wird das 
Zeitverhalten des Prozessors nicht mehr taktgenau, d. h. fur 

25 jeden Taktzyklus auf geschlusselt , dargestellt, sondern nur 
noch die Programme mit ihren Ein- und Ausgaben. Das Problem 
der Cosimulation liegt nun in der Kopplung der unterschied- 
lich abstrakten Modeller derart dass eine hinreichende Genau- 
igkeit der Simulation erreicht wird. Im ungunstigsten Fall 

30 greifen Prozessor und andere Hardwarekomponenten auf den 

gleichen Speicher zu. Eine genaue Modellierung erfordert in 
diesem Fall angepasste Speicher- und Busmodelle und spezielle 
Simulationstechniken. Ein Beispiel hierfiir bietet der Cosimu- 
lator Seamless CVS der Firma Mentor Graphics, Wilsonville, 

35 regon, USA. Das Produkt Seamless CVS benutzt ein abstraktes 
Prozessormodell, das die Bef ehlsausfiihrung nachbildet (ein 
sogenannter Instruction Set Simulator) . Fttr den Speicher- 



WO 2005/001720 



PCT/EP2004/004991 



zugriff werden Busmodelle verwendet, deren Abstraktion abhan- 
gig vom gleichzeitigen Zugriff von Prozessor und Hardware 
ist. Speicher, auf die lediglich der Prozessor zugreift, wer- 
den folglich abstrakter modelliert als solche, in denen Kon- 
5 flikte auftreten konnen. Voraussetzung ist also die Verfiig- 
barkeit einer Bibliothek von Modellen, die vom CAD-Anbieter 
oder dem Prozessorhersteller bezogen wird. 

Ein abstrakterer Ansatz reduziert das Prozessormodell auf die 
10 reine Programmausftihrung auf dem PC oder der Workstation und 
modelliert lediglich das Interface mit Zeitverhalten. Die 
Kopplung der Software-Ausfiihrung zum Hardwaremodell erfolgt 
dann tiber ein simulatorspezif isches Kommunikationsprotokoll, 
das der Entwickler in die Software einfiigen muss* Fur diese 
15 Modellierung sind nur Interf ace-Modelle erforderlich 7 was die 
Bibliotheksproblematik wesentlich vereinf acht . Andererseits 
wird das Zeitverhalten nur auf der Hardwareseite korrekt mo- 
delliert. Beispiel ftir einen solchen Cosimulator ist das Pro- 
dukt Eagle der Firma Synopsys, Mountain View, Kalifomien, 
20 USA. 
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Patentansprttche 

1. System zur Verknupfung und Darstellung von Signalen (4, 5) 
einer Vorrichtung zur Hardware-Simulation (1) und Elementen 

5 (15) eines Listings (2) eines Programms (3), 

• wobei die Vorrichtung zur Hardware-Simulation (1) das Ver- 
halten einer Schaltung (6) mit einem Prozessor (7), einem 
Programmspeicher (8), welcher den Programmcode (9) des 
Programms (3) enthalt, und applikationsspezif ischen Hard- 

10 warekomponenten (10) simuliert und Signale (4, 5) als Er- 

gebnis der Simulation erzeugt, 

• wobei die Elemente (15) des Listings (2) des Programms (3) 
mit den bei der simulierten Ausftihrung des im Programm- 
speicher (8) enthaltenen, mit diesen Elementen (15) kor- 

15 respondierenden Programmcodes (9) erzeugten Signalen (4, 

5) verkniipft werden, 

• wobei die Elemente (15) des Listings (2) des Programms (3) 
in einem ersten Teilbereich (11) eines graf ischen Anzeige- 
mittels (14) und die Signale (4, 5) in einem zweiten Teil- 

20 bereich (12) des Anzeigemittels (14) darstellbar sind. 

2. System nach Anspruch 1, 

dadurch gekennzeichnet, 
dass eine Markierung (20) eines Elements (15) des Listings 
25 (2) des Programms (3) im ersten Teilbereich (11) des grafi- 
schen Anzeigemittels (14) und eine Markierung (21) der mit 
diesem Element (15) verkntipften Signale (4, 5) im zweiten 
Teilbereich (12) des Anzeigemittels (14) vorgesehen ist. 

30 3. System nach Anspruch 1 oder 2, 

d a d.u rch gekennzeichnet, 
dass ein dritter Teilbereich (13) des graf ischen Anzeigemit- 
tels (14) zur Darstellung mindestens eines Teils der Signale 
(4, 5) vorgesehen ist. 

35 

4. System nach einem der vorhergehenden Anspriiche, 
dadurch gekennzeichnet, 
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dass die Schaltung (6) mit dem Prozessor (7), dem Programm- 
speicher (8) und den applikationsspezif ischen Hardwarekompo- 
nenten (9) in einer Hardware-Beschreibungssprache beschrieben 
sind. 

5. System nach einem der vorhergehenden Anspruche, 
dadurch gekennzeichnet, 
dass Mittel zum Anpassen des Systems an verschiedene Prozes- 
sortypen vorgesehen sind. 



6. Verfahren zur Verkniipfung und Darstellung von Signalen 
(4, 5) einer Vorrichtung zur Hardware-Simulation (1) und Ele- 
menten (15) eines Listings (2) eines Programms (3), 
• wobei die Vorrichtung zur Hardware-Simulation (1) das Ver- 
15 halten einer Schaltung (6) mit einem Prozessor (7), einem 
Programmspeicher (8), welcher den Programmcode (9) des 
Programms (3) enthalt, und applikationsspezif ischen Hard- 
warekomponenten (10) simuliert und Signale (4, 5) als Er- 
gebnis der Simulation erzeugt, 
20 • wobei die Elemente (15) des Listings (2) des Programms (3) 
mit. den bei der simulierten Ausfuhrung des im Programm- 
speicher (8) enthaltenen, mit diesen Elementen (15) kor- 
respondierenden Programmcodes (9) erzeugt en Signalen (4, 
5) verknttpft werden, 
25 • wobei die Elemente (15) des Listings (2) des Programms (3) 
in einem ersten Teilbereich (11) eines grafischen Anzeige- 
mittels (14) und die Signale (4, 5) in einem zweiten Teil- 
bereich (12) des Anzeigemittels (14) dargestellt werden, 

30 7. Verfahren nach Anspruch 6, 

dadurch gekennzeichnet, 
dass ein Element (15) des Listings (2) des Programms (3) im 
ersten Teilbereich (11) des grafischen Anzeigemittels (14) 
und die mit diesem Element (15) verknUpften Signale (4, 5) im 

35 zweiten Teilbereich (12) des Anzeigemittels (14) markiert 
werden. 
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8. Verfahren nach Anspruch 6 oder 7, 
dadurch gekennzeichnet, 

dass in einem dritten Teilbereich (13) des grafischen Anzei- 
gemittels (14) mindestens ein Teil der Signale (4, 5) darge- 
5 stellt wird. 

9. Verfahren nach einem der Anspruche 6 bis 8, 
dadurch gekennzeichnet, 

dass die Schaltung (6) mit dem Prozessor (7), dem Programm- 
10 speicher (8) und den applikationsspezif ischen Hardwarekompo- 
nenten (9) in einer Hardware-Beschreibungssprache beschrieben 
sind. 

10. Verfahren nach einem der Anspruche 6 bis 9, 
15 dadurch gekennzeichnet, 

dass das Verfahren an verschiedene Prozessortypen anpassbar 
ist . 

11. Fehlersuchwerkzeug zur Verkntipfung und Darstellung von 
20 Signalen (4, 5) einer Vorrichtung zur Hardware-Simulation (1) 

und Elementen (15) eines Listings (2) eines Programms (3), 

• wobei die Vorrichtung zur Hardware-Simulation (1) das Ver- 
halten einer Schaltung (6) mit einem Prozessor (7), einem 
Programmspeicher (8), welcher den Programmcode (9) des 

25 Programms (3) enthalt, und applikationsspezif ischen Hard- 
warekomponenten (10) simuliert und Signale (4, 5) als Er- 
gebnis der Simulation erzeugt, 

• wobei das Fehlersuchwerkzeug Mittel zur Verknupfung der E- 
lemente (15) des Listings (2) des Programms (3) mit den 

30 bei der simulierten Ausfiihrung des im Programmspeicher (8) 
enthaltenen, mit diesen Elementen (15) korrespondierenden 
Programmcodes (9) erzeugten Signalen (4, 5) aufweist, 
wobei die Elemente (15) des Listings (2) des Programms (3) in 
einem ersten Teilbereich (11) eines grafischen Anzeigemittels 
35 (14) und die Signale (4, 5) in einem zweiten Teilbereich (12) 
des Anzeigemittels (14) darstellbar sind. 
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